![[JAWS ミート 2024] 『踏み台の運用が変わる？ VPC 上で起動できるようになった CloudShell を語る』というタイトルで登壇しました。#jawsmt #jawsug](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f890958eb561d5bd7db7da1a250388ae/991bed17eecdc11214e20f27978b5553/jaws-ug-logo-1200x630.png){kind=logo}
[JAWS ミート 2024] 『踏み台の運用が変わる？ VPC 上で起動できるようになった CloudShell を語る』というタイトルで登壇しました。#jawsmt #jawsug
2024.07.06こんにちは、AWS 事業本部の平木です！
本日、愛知県豊橋市の BASE CAMP KITI にて開催された JAWS-UG 東海道主催の JAWS ミート 2024 にて、「踏み台の運用が変わる？ VPC 上で起動できるようになった CloudShell を語る」というタイトルで登壇したため登壇資料を公開します。
登壇資料
登壇内容
イントロダクション
皆さんは踏み台サーバを運用していますか？
踏み台サーバを運用しようと思うといくつか悩みの種が出てきます。
- 少し RDS へ接続したいだけの踏み台サーバなのに EC2 を停止しても EBS の料金が発生してしまう
- 踏み台サーバの分、脆弱性対策の対象が増えてしまう
- EC2 を構築する際に申請が必要な場合、わざわざ申請が面倒
など微妙に面倒に感じることないでしょうか。
そんな悩みを解決するかもしれないアップデートを今回ご紹介します。
※当該ブログは以下となります。
今までの踏み台
まず、今まで踏み台サーバを運用するときどんなだったかを思い出します。
初めに、プライベートサブネットの EC2 に接続する場合を考えると、
踏み台サーバを使用せずとも、Systems Manager のセッションマネージャーや EC2 Instance Connect endopoint を活用することで踏み台サーバの代替手段として採用できました。
それぞれの詳細と違いについては下記ブログを参照ください。
しかし、RDS や Redshift といったマネージドな DB に接続する場合を考えると、
結局踏み台サーバが必要でした。
そこで今回登場した CloudShell VPC environment を活用すると下記のように接続できます。
そんな CloudShell VPC environment について解説します。
CloudShell VPC environment について
CloudShell VPC environment は先月 6 月 13 日に追加された機能で文字通り、VPC 環境をサポートする機能となります。
こちらの機能は、
まずその名の通り、VPC 環境をサポートした機能です。
パブリック環境として提供されていた CloudShell がプライベートに使用することができるようになりました。
またアクセス制御はセキュリティグループで行います。
CloudShell VPC environment を構築時に ENI が払い出されその ENI にセキュリティグループが関連付けられます。
その他、CloudShell はマネージドサービスであるためパッチ適用などのセキュリティ面を AWS が行ってくれます。
構成イメージとしては以下です。
CloudShell とクライアントとの間は IAM 認証となるためポリシーに沿ってアクセス制御が可能です。
CloudShell と各 AWS リソースとの間はセキュリティグループによってアクセス制御が可能となります。
またインターネットへ出たい場合には、インターネットゲートウェイへのルーティングが存在すればインターネットへ出ることも可能です。
CloudShell を踏み台として活用することで、
- EC2 のインスタンス使用料を払う必要がなく
- パッチ適用の考慮も不要で
- サーバの構築も不要
などハッピーなことが盛りだくさんです。
ただ考慮すべき事項がいくつかあるため解説します。
考慮すべきこと
開発者や担当者は EC2 を立てずに踏み台を作成できるのでハッピーかもしれませんが、
管理者から見ると気軽にプライベート空間内に本番環境などに接続できる可能性のあるリソースを作成されると困ると考える組織も当然あると思います。
その場合はある程度制限をかけないといけないシチュエーションも当然出てきます。
それを見込んでか VPC 環境をサポートしたのと合わせて以下の IAM 条件キーが追加されました。
- CloudShell:VpcIds
- 1 つ以上の VPC を許可/拒否する
- CloudShell:SubnetIds
- 1 つ以上のサブネットを許可/拒否する
- CloudShell:SecurityGroupIds
- 1 つ以上のセキュリティグループを許可/拒否する
例えば下記のような使用例があります。
CloudShell:VpcIdsとNullを活用することで VPCIds のキーが存在する場合に CreateEnvironment アクションを制限可能です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCloudShellVpcEnvironments",
"Action": [
"cloudshell:CreateEnvironment"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"Null": {
"cloudshell:VpcIds": "false"
}}}]}
下記ブログにて他のパターンもご紹介しているためご参考にしていただければと思います。
その他にも、
- 「アクション」メニューからのデータのアップロード・ダウンロードは不可
- インターネットへ出れる環境であれば別のツールで実現可能
- 永続的なストレージは使用不可
- セッション終了時にホームディレクトリが削除されるため S3 へ保存などの仕組みが必要
- ログイン履歴といった監査ログの機能は現在のところなし
- CloudTrail では StartSession,StartEnvironment というレコードが記録されるが VPC 環境かどうかの判別不能
などの制約事項があるため考慮する必要があります。
まとめ
ということで最後まとめとなります。
今回新規で追加された CloudShell VPC environment によって踏み台サーバの運用に大きな変化が起きると思います。
しかし手軽にできるのが逆にネックになってしまったり監査証跡が取れないなど踏み台サーバとして 100%代替するのは難しそうですが最高のアップデートだと思いました。
ぜひみなさんもがっつり使用してリクエストがあれば AWS へフィードバックしましょう！
おわりに
今回は JAWS ミート 2024 に登壇してきた資料を公開しました。
LT の後は、参加者の皆さんと本編である BBQ を堪能しながら懇親を深め楽しい時間を過ごしました！
運営の皆様、準備などありがとうございました！
来年もタイミングがあえばぜひ参加したいと思います！
